MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 110

Internet Message Format | 1997-05-06 | 28KB

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-110

C.S.M.P. Digest             Sat, 16 Sep 95       Volume 3 : Issue 110

Today's Topics:

        Control action procedures
        Errors in PowerPC section of Mac Game Gurus book
        Implementing tear off menus? Where do I begin?
        KillPicture or DisposeHandle?
        New release of Chipmunk Basic
        TransSkel 3.22 is available (Thread Manager support added)
        [Q] How do I write a Photoshop plug-in?

The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news semi-regularly and want an archive of the discussions.
If you don't know what a newsgroup is, you probably don't have access to
it. Ask your systems administrator(s) for details. If you don't have access
to news, you may still be able to post messages to the group by using a
mail server like anon.penet.fi (mail [e-mail] for more
information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Mark Suska)
Subject: Control action procedures
Date: Wed, 30 Aug 1995 01:50:21 GMT
Organization: Carleton University

I am trying to get an action procedure for the scrollbar indicator to
work. I have no problems getting the action procedures to work for other
controls or other regions of the scrollbar. I know that the action
procedure for indicators takes no parameters unlike the action procedures
for other areas which take two parameters, the control handle and the part
code.
Right now the action procedure is called correctly the first time but the
application exits immediately after returning from it.
I've traced it with a debugger and can it seems to crash in the system
code wich called my action procedure.
Is there something special that you have to do in this action procedure? I
don't return anything from the procedure, should I?
Any suggestions as to what I am doing wrong?

Thanks for your help.

--
Mark Suska,
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (F. Degott)
Date: 30 Aug 1995 12:08:20 GMT
Organization: LMC-IMAG Grenoble France

In article <ug930175-2908952150210001@1.1.1.1>,
[e-mail] (Mark Suska) wrote:

>I am trying to get an action procedure for the scrollbar indicator to
>work. I have no problems getting the action procedures to work for other
>controls or other regions of the scrollbar. I know that the action
>procedure for indicators takes no parameters unlike the action procedures
>for other areas which take two parameters, the control handle and the part
>code.
>Right now the action procedure is called correctly the first time but the
>application exits immediately after returning from it.
>I've traced it with a debugger and can it seems to crash in the system
>code wich called my action procedure.
>Is there something special that you have to do in this action procedure? I
>don't return anything from the procedure, should I?
>Any suggestions as to what I am doing wrong?
>

Hi Mark,
see the IM extract of Dialog Manager below, about TrackControl proc.
it seems that the ActionProc must have two differents headers
according to the type of control.

FUNCTION TrackControl (theControl: ControlHandle; startPt: Point;
    actionProc: ProcPtr) : INTEGER;

[...]

    TrackControl may take additional actions beyond highlighting the
control or dragging the indicator, depending on the value passed in the
actionProc parameter, as described below. Here you'll learn what to
pass for the standard control types; for a custom control, what you
pass will depend on how the control is defined.

      - If actionProc is NIL, TrackControl performs no additional
        actions. This is appropriate for simple buttons, check boxes,
        radio buttons, and the thumb of a scroll bar.
      - ActionProc may be a pointer to an action procedure that defines
        some action to be performed repeatedly for as long as the user
        holds down the mouse button. (See below for details)
      - If actionProc is POINTER(-1), TrackControl looks in the control
        record for a pointer to the control's default action procedure.
        If that field of the control record contains a procedure
        pointer, TrackControl uses the action procedure it points to; if
        the field contains POINTER(-1), TrackControl calls the control
        definition function to perform the necessary action. (If the
        field contains NIL, TrackControl does nothing.)

    The action procedure in the control definition function is described
in the section "Defining Your Own Controls". The following paragraphs
describe only the action procedure whose pointer is passed in the
actionProc parameter or stored in the control record.

    If the mouse button was pressed in an indicator, the action
procedure (if any) should have no parameters. This procedure must allow
for the fact that the mouse may not be inside the original control part.

    If the mouse button was pressed in a control part other than an
indicator, the action procedure should be of the form

    PROCEDURE MyAction (theControl: ControlHandle; partCode: INTEGER);

    In this case, TrackControl passes the control handle and the part
code to the action procedure. (It passes Ø in the partCode parameter if
the mouse has moved outside the original control part.)  As an example
of this type of action procedure, consider what should happen when the
mouse button is pressed in a scroll arrow or paging region in a scroll
bar. For these cases, your action procedure should examine the part
code to determine exactly where the mouse button was pressed, scroll up
or down a line or page as appropriate, and call SetCtlValue to change
the control's setting and redraw the thumb.

(warning)
    Since it has a different number of parameters depending
    on whether the mouse button was pressed in an indicator
    or elsewhere, the action procedure you pass to
    TrackControl (or whose pointer you store in the control
    record) can be set up for only one case or the other. If
    you store a pointer to a default action procedure in a
    control record, be sure it will be used only when
    appropriate for that type of action procedure. The only
    way to specify actions in response to all mouse-down
    events in a control, regardless of whether they're in an
    indicator, is via the control definition function.

Hope this helps.
Fr
- -----------------------------------------------------------------------
FR Degott ([e-mail])
Lab. LMC-IMAG - UJF - Grenoble - France
- -----------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Bob Bradley)
Date: Wed, 30 Aug 1995 18:01:11 -0700
Organization: SPC

In article <ug930175-2908952150210001@1.1.1.1>,
[e-mail] (Mark Suska) wrote:

>I am trying to get an action procedure for the scrollbar indicator to
>work. I have no problems getting the action procedures to work for other
>controls or other regions of the scrollbar. I know that the action
>procedure for indicators takes no parameters unlike the action procedures
>for other areas which take two parameters, the control handle and the part
>code.

I posted a replacement for TrackControl that handles clicks in the thumb
portion of the correctly (and uses the normal TrackControl for parts that
it handles correctly). If you can't find it, leave me mail and I'll send
it to you.

+++++++++++++++++++++++++++

>From [e-mail] (Ari Halberstadt)
Date: Thu, 31 Aug 1995 22:49:26 -0400
Organization: North Shore Access/Eco Software, Inc; ([e-mail])

In article <[e-mail]>,
[e-mail] (F. Degott) wrote:

>In article <ug930175-2908952150210001@1.1.1.1>,
>[e-mail] (Mark Suska) wrote:
>
>>I am trying to get an action procedure for the scrollbar indicator to
>>work. I have no problems getting the action procedures to work for other
>...
>see the IM extract of Dialog Manager below, about TrackControl proc.
>it seems that the ActionProc must have two differents headers
>according to the type of control.

I use the following code to avoid this split-personality aspect of
TrackControl. Anything with "ws" calls to my libs.

/* function passed to wsCtlTrack */
typedef void (*wstControlTrack)(wstControl ctl,
   wstInteger part, void *data);

/* data needed by mouse tracking call-back function */
typedef struct {
   wstControlTrack proc;
   wstControl ctl;
   wstInteger part;
   void *data;
} ControlTrackStructure;

/* global for access from action and indicator callbacks */
static ControlTrackStructure *gTrack;

/* function passed to TrackControl for clicks in parts other than indicators */
static pascal void CtlTrackAction(ControlHandle macctl, short part)
{
   #pragma unused (macctl)
   ControlTrackStructure *track = gTrack;

   ws_check(wsCtlValid(track->ctl));
   ws_check(track->proc != NULL);
   track->proc(track->ctl, part, track->data);
}

/* function passed to TrackControl for clicks in indicators */
static pascal void CtlTrackIndicator(void)
{
   ControlTrackStructure *track = gTrack;

   ws_check(wsCtlValid(track->ctl));
   ws_check(track->proc != NULL);
   track->proc(track->ctl, track->part, track->data);
}

/* ƒwsCtlTrack tracks the mouse in the control. The 'proc' parameter may
   be a pointer to a function to call while the mouse is held down,
   or it may be (ControlProcType)-1L, or NULL. The 'data' parameter
   is passed to the function pointed to be the 'proc' parameter, and
   may contain any application defined data. A control part code is
   returned if the mouse is released in an active part of the control,
   otherwise zero is returned. See the description of the Toolbox routine
   TrackControl for more details. */
wstInteger wsCtlTrack(wstControl ctl,
   const wssPoint *where,
   wstControlTrack proc,
   void *data)
{
   static ControlActionUPP uppCtlTrackAction;   /* UPP for action function */
   static DragGrayRgnUPP uppCtlTrackIndicator;  /* UPP for action function */
   ControlTrackStructure track;  /* information for action function */
   ControlHandle dummy;          /* dummy parameter for FindControl */
   wstBoolean indicator;         /* true if clicked in indicator */
   wssQDPoint qdpt;              /* point that was clicked */
   wstInteger part;              /* part that was clicked */
   wssPortState state;           /* saved state of port */

   ws_require(wsCtlValid(ctl));
   if (! uppCtlTrackAction) {
      uppCtlTrackAction = NewControlActionProc(CtlTrackAction);
      wsThrowIfNull(uppCtlTrackAction);
   }
   if (! uppCtlTrackIndicator) {
      /* see comment in <Controls.h>, it says to use a DragGrayRgnUPP */
      uppCtlTrackIndicator = NewDragGrayRgnProc(CtlTrackIndicator);
      wsThrowIfNull(uppCtlTrackIndicator);
   }
   if (wsCtlStyle(ctl) == wskCtlStylePopupMenu) {
      /* it's a popup menu, so adjust the menus before it's selected */
      wsEventMenuAdjust();
   }
   wsPointToQDPoint(where, &qdpt);
   wsGPortSetup(wsPanePort(ctl->pane), &state);
   if (proc != NULL && proc != (wstControlTrack) -1L) {
      part = FindControl(qdpt, GetControlOwner(ctl->macctl), &dummy);
      indicator = (part > 128);
      track.ctl = ctl;
      track.data = data;
      track.proc = proc;
      track.part = part;
      ws_check(! gTrack);
      gTrack = &track;
      if (indicator)
         part = TrackControl(ctl->macctl, qdpt, (ControlActionUPP)
uppCtlTrackIndicator);
      else
         part = TrackControl(ctl->macctl, qdpt, uppCtlTrackAction);
      gTrack = NULL;
   }
   else
      part = TrackControl(ctl->macctl, qdpt, (ControlActionUPP) proc);
   wsGPortRestore(wsPanePort(ctl->pane), &state);
   return(part);
}

Here's a little bonus :-)

/*---------------------------------------------------------------------------*/
/* Definitions for Strict Controls (until Apple provides them) */
/*---------------------------------------------------------------------------*/

#define ControlIsVisible(ctl)    (((**(ctl)).contrlVis) != 0)
#define GetControlHilite(ctl)    ((**(ctl)).contrlHilite)
#define GetControlData(ctl)      ((**(ctl)).contrlData)
#define GetControlRect(ctl, r)   ((void) ((*r) = (**(ctl)).contrlRect))
#define GetControlOwner(ctl)     ((**(ctl)).contrlOwner)
#define GetControlProc(ctl)      ((**(ctl)).contrlDefProc)

-- Ari Halberstadt ([e-mail])

---------------------------

>From [e-mail] (Lawson English)
Subject: Errors in PowerPC section of Mac Game Gurus book
Date: 2 Sep 1995 10:09:36 GMT
Organization: Primenet [phone]

Well, I was all excited when I picked up _Tricks of the Mac Game
Programming Gurus_. Overall, it does look like a nice book.


However, there are some rather BAD errors in the chapter on PowerPC
optimization. There are errors of fact (e.g. "low-end PowerPC's have 5
instructional units that can work simultaneously and complete up to three
instructions per cycle") and errors in interpreting timing information.

The chapter applies this misinterpretation to optimizing a full-screen
blit without even providing an optimized CopyBits version as a benchmark,
and thereby hangs the tale...


The author of the chapter asserts that double floating point stores take 3
cycles to complete. This is *best* case and doesn't apply when all loads
and stores are done using the same  floating point register in a
massively-unrolled loop.


The author is excited by the fact that one can get a 3% increase in speed
by unrolling the blitting loop so that a full scanline is blitted per
iteration of the loop (i.e. 80 in-line instructions).


No attempt at pipelining by using multiple registers is discussed or
attempted. No mention of any possible assembly-level optimizations
(e.g. touching the cache) is made. No discussion of the branch prediction
unit and how that effects unrolling of loops is made. No discussion of
how the slow speed of the VRAM video bus justifies using the slower
double load/store-based blitting instead of the the theoretically faster
integer load/store. The author also somehow misreads the timing of the
double load and assumes that it is identical to the double store, and
that one can simply add instructions' cycle times to calculate the time
it takes to execute a given instruction stream.

Nor is any discussion made of how these issues might change with the 604 CPU.

Nor is any discussion made of how to determine whether a video card with
accelerated blitting might be faster, so that Apple's CopyBits (which
transparently uses hardware-based blitters, as I recall) might be the
better bet.

Since the author never times CopyBits, we can't even see how his/her
"optimized" version does against Apple's own. I suspect that Apple's generic
blitter can do better than the author's hand "optimized" one.

I'm the first to admit that I don't understand the PowerPC optimization
issues all that well, but the author appears (to my limited
understanding) to be even more clueless than I.

Disappointing, to say the least. Hopefully the rest of the book is more
fact-full...



--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

---------------------------

>From "Stephen E. Maas" <[e-mail]>
Subject: Implementing tear off menus? Where do I begin?
Date: Mon, 28 Aug 1995 19:13:29 GMT
Organization: Maasware Enterprises

Where do I start looking for information implementing global tear off
menus? Was there a tech. note written on the subject? Are there any
files or code examples out there documenting how it is done? I am not
asking for help yet, just a nudge in the proper direction. Thanks.




+++++++++++++++++++++++++++

>From [e-mail] (Ed Samuels)
Date: 29 Aug 1995 00:43:31 -0400
Organization: The Pipeline

In article <[e-mail]>, Stephen E. Maas writes:

>Organization: Maasware Enterprises
>Mime-Version: 1.0
>Date: Mon, 28 Aug 1995 19:13:29 GMT
>X-Mailer: Mozilla 1.1N (Macintosh; I; 68K)
>X-Url: news:comp.sys.mac.programmer.help
>Lines: 7
>
>Where do I start looking for information implementing global tear off
>menus? Was there a tech. note written on the subject? Are there any
>files or code examples out there documenting how it is done? I am not
>asking for help yet, just a nudge in the proper direction. Thanks.
>
>
>
>

I'd recommend creating your own MDEF, a menu definition procedure, instead
of that complicated custom-font thing that Hypercard and the TCL use.
Divide the menu up into rectangles with pictures in them (with something
like an 'nrct' resource) and track as the user moves the mouse over those
rectangles. When the user tracks outside of the menu + a certain border,
start dragging the tear-off around, and finish by posting an apple event to
your application to move the tear-off palette to that location. For info
about writing MDEFs, look at the New Inside Mac:Mac Toolbox Essentials,
page 3-87.

- ---------------------------------------------------------------------------------------------------

Richard Samuels
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Tue, 29 Aug 1995 14:21:47 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Stephen E. Maas ([e-mail]) wrote:
: Where do I start looking for information implementing global tear off
: menus? Was there a tech. note written on the subject? Are there any
: files or code examples out there documenting how it is done? I am not
: asking for help yet, just a nudge in the proper direction. Thanks.

ftp ftp.info.apple.com, the DTS.Draw source, for one.  Also, Nigel
Perry's "Pictoid" source has something similar (don't know if it tears off).

There's an init or control panel that implements global tear-offs
already.  "Why code it if somebody already wrote it" is a time and
trouble saving maxim.

-Ken-

---------------------------

>From [e-mail] (Alex Tang)
Subject: KillPicture or DisposeHandle?
Date: 31 Aug 1995 16:28:03 GMT
Organization: University of Michigan

sorry if this is a newbie question....

When drawing picts using:

hPict = PicHandle ( NewHandle ( nDataLength ) );
FSRead ( nFileRef, &nCount, ( Ptr ) *hPict );
HLock ( ( Handle ) hPict );
DrawPicture ( hPict, &rectPict );
HUnLock ( ( Handle ) hPict );

should i use DisposeHandle() or KillPicture() to finish up.

Thanx.
...alex...

+++++++++++++++++++++++++++

>From [e-mail] (AndrewWelc)
Date: 31 Aug 1995 13:22:16 -0400
Organization: America Online, Inc. (1-800-827-6364)

> should i use DisposeHandle() or KillPicture() to finish up.

Either -- KillPicture just calls DisposeHandle() anyway (and does nothing
else).

Regards,

Andrew Welch
Thaumaturgist
Ambrosia Software, Inc.

..........

For the latest versions of our software, technical support, and Ambrosia
news, stop by and visit the Ambrosia Software, Inc. support forums:

America Online ---> Keyword: Ambrosia
    CompuServe ---> GO word: Ambrosia
        eWorld --> Shortcut: Ambrosia
>From [e-mail] (Alex Tang)

---------------------------

>From Ron Nicholson <[e-mail]>
Subject: New release of Chipmunk Basic
Date: 29 Aug 1995 01:12:05 GMT
Organization: Silicon Graphics, Inc.

I'm not sure how many c.s.m.p folks still consider writing stuff in the
BASIC language as a form of programming...

But, in case you're still one of the few, there's a new release of
Chipmunk Basic, vers. 3.2.1.   It's a bug fix release with a few minor
enhancements.

Already in the Info-Mac archives and also here:
<ftp://ftp.rahul.net/pub/rhn/chipmunk-basic-321.hqx>

Looks like Chipmunk Basic may soon be obsoleted by the rumored "Kenobi"
and "Danali" implementations.

- -
Ronald H. Nicholson, Jr.                [e-mail], [e-mail]
#include <canonical.disclaimer>         // I speak only for myself, etc.


---------------------------

>From [e-mail] (Paul DuBois)
Subject: TransSkel 3.22 is available (Thread Manager support added)
Date: 1 Sep 1995 12:10:41 -0500
Organization: UW-Madison Primate Center

Release 3.22 of TransSkel, a skeleton for Macintosh application development
under MetroWerks C or Pascal or Symantec C++/THINK C, is now available.

This is an update release; it provides Thread Manager support.
It also fixes a bug so that the TransSkel library correctly knows
the application is suspended when launched directly into the
background.

Thread Manager support and the bugfix were both contributed by
Hans van der Meer, [e-mail].  My thanks to him.

TransSkel is available via any of the following:

anonymous ftp to ftp.primate.wisc.edu (under /pub/mac/TransSkel)

gopher to gopher.primate.wisc.edu, then select "Primate Center Software
Archives")

WWW using URL http://www.primate.wisc.edu/software/mac/TransSkel/
--
Paul DuBois
[e-mail]
Home page: http://www.primate.wisc.edu/homepage/dubois
 Software: http://www.primate.wisc.edu/software

---------------------------

>From [e-mail] (Brett M. Wayne)
Subject: [Q] How do I write a Photoshop plug-in?
Date: 30 Aug 1995 16:40:17 GMT
Organization: Initial Point Software


I am working on a ground station support package for a spacecraft that
has as part or its sensor suite, several imaging sensors. The ground
station
is being developed on a Silicon Graphics workstation so I'm not at a loss
for compute cycles.

My current path to getting processed imagery into finished documents is to
translate the raw imagery into some standard format (i.e. TIFF, GIF, etc. )

before I pull them into Photoshop. The main problem with this is that I
lose
all of the non-pixel meta-data in the translation.  It would be neat
if I could write a simple Photoshop plug-in that would enable me to
import/export the images in their native, definitely non-standard format.

I'm not a newbie to Mac programming. I've programmed using both
Codewarrier,
and Symmantec C++/TCL, Resedit, Resorcerer, etc.  If anyone has had
experience
doing this, I'd greatly appreciate pointers to references, additional tools
required, etc.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Brett M. Wayne
University of California
Lawrence Livermore National Laboratory
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (kemper)
Date: 31 Aug 1995 04:37:36 GMT
Organization: San Diego State University Computing Services


Adobe's plugin architecture for Photoshop is on the the CW CD.  You
can also join their developer's program for more info, or buy one
of their special CD thingies =).


Brett M. Wayne ([e-mail]) wrote:

: I am working on a ground station support package for a spacecraft that
: has as part or its sensor suite, several imaging sensors. The ground
: station
: is being developed on a Silicon Graphics workstation so I'm not at a loss
: for compute cycles.

: My current path to getting processed imagery into finished documents is to
: translate the raw imagery into some standard format (i.e. TIFF, GIF, etc. )

: before I pull them into Photoshop. The main problem with this is that I
: lose
: all of the non-pixel meta-data in the translation.  It would be neat
: if I could write a simple Photoshop plug-in that would enable me to
: import/export the images in their native, definitely non-standard format.

: I'm not a newbie to Mac programming. I've programmed using both
: Codewarrier,
: and Symmantec C++/TCL, Resedit, Resorcerer, etc.  If anyone has had
: experience
: doing this, I'd greatly appreciate pointers to references, additional tools
: required, etc.


: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
: Brett M. Wayne
: University of California
: Lawrence Livermore National Laboratory
: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Chris De Salvo)
Date: Thu, 31 Aug 1995 01:15:42 -0700
Organization: MacPlay

In article <[e-mail]>, [e-mail] (Brett M.
Wayne) wrote:

> before I pull them into Photoshop. The main problem with this is that I
> lose
> all of the non-pixel meta-data in the translation.  It would be neat
> if I could write a simple Photoshop plug-in that would enable me to
> import/export the images in their native, definitely non-standard format.

At any of the Info-Mac mirros you can find the Photoshop Developers Kit.
It includes sample source for import and export plug-ins.  In the Info-Mac
hierarchy it is at:

   _Development
         _Library
               photoshop-kit.hqx>

Good luck,
Chris

--
+-----------------------------------------------------------------+
| [e-mail]         |   Macintosh:  Changing the world, |
| Chris De Salvo              |        one person at a time!      |
| Professional Mac Geek       |    -----------------------------  |
| for MacPlay, Inc.           |      (I wish they'd hurry up!)    |
+-----------------------------------------------------------------+

Any opinions expressed, or implied, are my own!  They should not be
considered representative of the opinions or policies of my employer,
MacPlay, a division of Interplay Productions, Inc.

+++++++++++++++++++++++++++

>From Darren Giles <[e-mail]>
Date: Thu, 31 Aug 1995 08:21:29 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Adobe has a SDK for Photoshop plug-ins.  Believe it or not,
it's already on the CodeWarrior CD.  You could also check their
WWW site (http://www.adobe.com/), or give 'em a call.

Best of luck!

- Darren

==========================================================================
Darren Giles, Technical Director                           [e-mail]
Terran Interactive                               http://www.terran-int.com


---------------------------

End of C.S.M.P. Digest
**********************